在開始前，先聊聊為什麼要談「重構」。
在這個 vibe coding 興盛、各家 AI 神仙打架的年代，重構顯得無趣許多。但我覺得重構更貼近每個工程師的日常。的確，AI 又潮又酷又方便，可是我們每天面對的，往往是那些又長又亂、動不得的程式碼。

想像身處老舊的大型專案危樓中，寫錯一行整棟大樓就會炸掉。你的 AI 同事好心的幫你改了上千行程式碼，一開始你試著用肉眼 review，看到一半開始跳行。你想到可以用 TDD 先寫測試，結果一細看，發現 AI 同事巧妙地把每個測試都繞過，來製造全數通過的假象。最終上線時還是出了包，你賠了年終，而你的 AI 同事還問你需不需要提供離職信的範本。

這種情況，我更相信 IDE 的「安全重構」。

市面上已經有很多談重構的書籍，隔壁的 senior 同事一定會跟你說：「重構前一定要先加測試！」可是現實哪有那麼美好，你一定遇過的，當程式碼耦合到一定程度，想加測試還得先重構，啊要重構前要加測試，這不就循環依賴嗎？這時候又該怎麼辦。這時另一邊的 senior 同事跟你說：「舊的程式碼跑得好好的，不要動！」PM 還跑來參一腳：「要不要放包乖乖？」

「重構前一定要先加測試！」這話沒錯，但也不是鐵律。這次我想換個角度，帶大家認識一種特別的重構 —— 安全重構。很多情況下，IDE 的自動化功能能幫我們安全地做改名、抽方法、搬移類別，根本不需要額外的測試就能有很高的信心。我不確定是否真的有這個「安全重構」這個術語，但我的定義是：那些不用測試，也能信心十足的重構

在繼續進行下去之前，有幾個關於重構的大前提：

1. 不改變功能
2. 不修 bug
   重構的定義就是「在不改變行為的前提下，改善程式結構」。原本是壞的東西在重構後還是壞的，我們只是專注在程式碼結構更清晰，讓它壞得更顯而易見，也更好修。

希望對面的 junior 同事，不要再說這程式太難改了，改不動啊！